home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14024 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.7 KB  |  117 lines
  1. Path: news.sdm.de!wagner
  2. From: wagner@sdm.de (Dr. Klaus Wagner)
  3. Newsgroups: comp.object,comp.lang.c++
  4. Subject: Re: Defining Object Associations
  5. Followup-To: comp.object,comp.lang.c++
  6. Date: 28 Mar 1996 14:30:47 GMT
  7. Organization: sd&m GmbH & Co. KG, Munich, Germany
  8. Message-ID: <4je7qn$hlr@sunti1.sdm.de>
  9. References: <4j9ens$jtq@crchh327.rich.bnr.ca>
  10. Reply-To: wagner@sdm.de
  11. NNTP-Posting-Host: sunfi1.fi.sdm.de
  12. X-Newsreader: TIN [version 1.2 PL2]
  13.  
  14. In <4j9ens$jtq@crchh327.rich.bnr.ca>, Joseph wrote:
  15.  
  16. > For example, a LoggingManager object and DisplayManager object
  17. > must be most constructed before creating a CommandDispatcher.
  18. > Yet the CommandDispatcher also requires that an EventManager
  19. > has been created, etc.
  20.  
  21. Although you didn't say it explicitly, it semms to me as 
  22. the Objects you are dealing with are mostly uniq in 
  23. your system. They are *singletons*. aren't they?
  24.  
  25. If this is true and you dont know about singletons,
  26. see the patterns literature for the singleton pattern.
  27.  
  28.  
  29. > So I have code that goes along creating these objects, and
  30. > when I create the CommandDispatcher I say,
  31.  
  32. > CommandDispatcher* CD = new CommandDispatcher(LM, DM, EM);
  33.  
  34. > etc.
  35.  
  36. One way to solve this, if you do have singletons is to
  37. use static lazy access methods for the singletons which 
  38. your constructors call on initialization.
  39.  
  40. Looks like this:
  41.  
  42. class LM { 
  43.   public: LM * get_the_LM() { 
  44.      static LM lm;
  45.      return &lm;
  46.   }
  47.   private: LM(...) {...}
  48. };
  49. class DM ... etc ...
  50.  
  51. class CommandDispatcher { 
  52.   public:
  53.   CommandDispatcher()
  54.   : pLM( LM::get_the_LM() ),
  55.     pDM( DM::get_the_DM() ),
  56.     pEM( EM::get_the_EM() )
  57.   { .. do your stuff with *pLM etc }
  58.  
  59.   private:
  60.     LM * pLM;
  61.     ....
  62. };
  63.  
  64. Doing so, you still have to add it to the Ctor-implementation,
  65. but not to the interface, which hinderes changes to 
  66. propagate wildly through your application code.
  67. And you dont any longer have to care about the order of 
  68. construction of those singeltons. The little clause 'static'
  69. in the accesors of the singletons just handle all this for
  70. you.
  71.  
  72. Provided that there are no cycles in this process of 
  73. propagating construktion of singletons.
  74.  
  75. If you do have cycles, you are lost anyway.
  76. But changing the above code only slightly can help you
  77. to detect this kind of loops automaticley at runtime.
  78. I know this is a very unsatisfactory promise, but anything 
  79. else you have to figer out your self by looking at your object
  80. modell.
  81.  
  82. > But whenever the CommandDispatcher needs to talk a different
  83. > type of object, I have to add it to the constructor and also
  84. > ensure that the new object has all of its requirements
  85. > fulfilled before created the CommandDispatcher.
  86.  
  87. > This presents a headache because I have to worry about the
  88. > order in which I create all of these things, and my code
  89. > is rearranged a lot.
  90.  
  91. > So what I would like is a global container of references to
  92. > pointers that I can attach to each object as I declare its
  93. > pointer (before I new it).  Then when I'm ready to new it
  94. > I pass in all of the references (via a single struct or
  95. > some sort) and everybody knows about everybody else.
  96.  
  97.  
  98. So, in essence, the above proposal *is* using a global container.
  99. The container is managed by the compiler in the static data area
  100. and you don't have to care about layout and initialization.
  101. But you hide it behind some accessor and so you have allways the
  102. freedon to rethink and change this decission.
  103.  
  104.  
  105. Hope this helps
  106.  
  107. --
  108.  
  109. Gruss - Klaus
  110.  
  111.  
  112. Klaus Wagner             |s  |d &|m  |  software design & management, Ltd.   
  113.                          |   |   |   |  Thomas-Dehler-Str. 27 (division FI)
  114.                          |   |   |   |  81737 Munich, Germany
  115. Tel:+49-89-63812-333     |   |   |   |  Fax.: +49-89-63812-490
  116.     +49-89-92446272(hypo)|   |   |   |  Internet: wagner@sdm.de
  117.